Computer-based telecommunications systems have proliferated in the last few years along with the common proliferation of high-speed personal computers and the generally lower costs of equipment now available for use in complex telecommunications applications. With the use of high-speed telephone switching lines, telecommunications applications are exhibiting rapid advancements in technology and versatility. One of the areas in which telecommunications has experienced rapid advancements is the "voice processing" industry, wherein telephone lines provide communication links between users calling in to obtain information from a computer-based system that is adapted to provide information about a particular business or organization.
The voice processing industry provides "voice-based" systems which interact in varying degrees with users seeking information from the system. Voice-based systems have evolved over the last several years into discrete systems which accomplish specific tasks. Thus, the voice processing industry is broken up into a series of "sub-technologies" which are occupied by particular providers and which are further segregated according to the products and services available in the specific sub-technology area. Generally, the voice processing industry has developed the following sub-technology areas: voice messaging ("VM") technology, call processing ("CP") technology, interactive voice response ("IVR") technology, and a number of other limited technologies which at the present are not large and do not command significant market shares, such as for example, the "FAX voice response" technology area. VM systems automatically answer calls and act as "automated attendants" to direct the calls to the proper person or department in an organization. These systems have in the past usually comprised look-up databases that perform voice functions for the user as the user accesses the system. VM technology can be adapted to read electronic mail to a user or caller on a telephone, and may also provide means for storing incoming facsimile messages for forwarding these messages over TOUCHTONE telephones when so instructed. Systems that fall under the VM category may also be adapted to recognize spoken phrases and convert them into system usable data.
Previous VM systems are exemplified in U.S. Pat. No. 4,585,906, Matthews et al. The Matthews et al. patent discloses an electronic voice messaging system which is connected with a user's telephone communications network or private branch exchange (PBX) to provide VM functions for the user. See Matthews et al., col. 4, lines 49-66.
Another example of a VM system is disclosed in U.S. Pat. No. 4,926,462, Ladd et al. The device of the Ladd et al. patent provides methods of handling calls in a VM system based on information supplied by a PBX. See Ladd et al., col. 4, lines 50-52. VM systems taught in the Ladd et al. patent comprise a feature phone emulator interface which emulates known PBX compatible feature phones having multiple line capability. The feature phone emulator is interfaced to the PBX as an actual feature phone, and the PBX is configured to assign a group of extension numbers to line appearances on the feature phone. The VM systems disclosed in the Ladd et al. patent answer the calls to these extensions by using the feature phone emulator interface. See Ladd et al., col. 4, lines 53-65.
Yet another VM system is disclosed in U.S. Pat. No. 4,811,381, Woo et al. The Woo et al. patent discloses a VM system which is connected to a trunk side of a PBX in a business telephone system. The VM system described in Woo et al. provides the feature of answering forwarded calls with a personal greeting from the party whose phone is accessed by a user. See Woo et al., col. 2, lines 37 through col. 2, lines 40-54.
If on the other hand a customer requires a voice processing system to perform on-line transaction processing and interact with a called to answer routine questions about the status of an account, for example, the customer's requirements are usually best addressed by an IVR system which can be viewed as fulfilling requirements presented by a totally different set of architectural problems. Essentially, in an IVR system the user desires to talk to a central processing unit (CPU) to obtain database information. IVRs are particularly useful in the banking industry wherein account holders can call a CPU to get account balances and other relevant information. Generally, IVR systems must also interface to a TOUCHTONE telephone to allow the caller to provide meaningful data to the IVR system which then can return meaningful information to the user.
When a retail company wishes to sell large volumes of merchandise through a "call-in ordering" system, it requires a call processing (CP) system. In the past, before CP systems were available, such retail companies utilized "agents" to handle incoming calls. The agents typically manned a switchboard that allowed manual input of user orders to an ordering system which could have been computer-based. CP technology today provides automatic call distribution ("ACD") which allows a company to nearly eliminate the need for live agents handling phone calls, and replaces the agent with an interactive telephone system through which products can be ordered. The products can be paid for by credit cards having credit card numbers which are input through a TOUCHTONE telephone to a computer ordering system for billing purposes.
Other examples of CP technology are taught in U.S. Pat. No. 4,850,012, Mehta et al. The Mehta et al. patent discloses a CP system for intercepting incoming calls to a key telephone system, and returning a message to a calling party. See Mehta et al., col. 2, lines 11-17. The Mehta et al. system further provides an intercom line for providing voice announcements or messages through the key telephone system to the called parties. CP systems described in Mehta et al. comprise a call processor which intercepts telephone calls wherein an instructional message is returned to the calling party, thereby informing the calling party to select a party associated with the key telephone system by dialing a pseudo-extension number associated with each party. See Mehta et al., col. 2, lines 18-28.
Other technologies have been developed to provide the particular services and solutions to other niches and sub-technologies in the voice processing industry. Interactive FAX voice processing is a burgeoning sub-technology area an has required specialized technical advancements to provide efficient voice-activated FAX systems. The technical advancement required to make FAX voice processing and other advanced voice processing systems feasible have not heretofore been adequately developed. There is a long-felt need in the art for a general-purpose system which can effectively, economically, and efficiently provide these technological advancements and which will integrate the above-mentioned other voice-based technologies in the voice processing field.
Examples of such systems for data reception and projection over telephone lines are disclosed in U.S Pat. Nos. 4,481,574, DeFino et al., and 4,489,438, Hughes. Both the DeFino et al. and Hughes patent teach hard-wired systems which interface to telephone lines and computers to provide telecommunications applications. However, the systems disclosed in the DeFino and Hughes et al. patents generally perform the telecommunications transactions in hardware, thus requiring expensive and bulk equipment to accomplish these applications.
All of the above-referenced patents disclose voice-based systems which are discrete and which perform narrow, limited voice-based transactions. If a customer needs a voice messaging system, a device such as that disclosed, for example, in the Matthews et al. patent could be purchased. However, if the customer also needs a system to interact with callers and to answer routine questions about the status of, for example, their bank accounts, a separate IVR system would be necessary. Similarly, if a customer needs to perform retail ordering and accounts management, a separate CP system such as that disclosed in the Mehta et al. patent must be purchased. Thus, it can be seen that the problem facing a customer who requires multiple voice processing functions is that of the proliferation of a multitude of special purpose systems that are expensive to purchase and to maintain, and which potentially process telephone calls in separate and disjoint manners.
An illustrative example will provide to those with skill in the art an appreciation of the magnitude of this problem. Consider a bank that allows its users to inquire about the balance of their account using an IVR system, but must now transfer a call to a VM system if the caller wishes to leave a message for an officer of the bank that could not be reached. This creates several problems for both the bank and the user. First, the bank must purchase and maintain at least two voice processing systems, an IVR system and a VM system. Second, the user must wait while one system addresses the other system to provide the new voice processing function. Third, the bank has no way of getting a consolidated report of the handling of a given call from start to finish. Fourth, if the user decides that since the bank officer is not available and the IVR system can provide additional information to answer a particular question, the transfer back to the IVR takes a considerable amount of time and is complicated since the user must usually enter the entire identification password information again, thereby leaving the bank without any way to trace a particular call as it is routed from one discrete voice processing system to the other.
As more discrete voice processing systems proliferate in a single environment, the problem of multiple disjoint systems becomes even more complex. There is a long-felt need in the art for methods and systems which integrate the various disparate voice processing functions to provide a voice processing system which effectively and economically provides all of the desired voice processing function for a customer. This need has not been fulfilled by any of the prior voice processing systems heretofore discussed, which only focus narrowly on one particular sub-technology in the complex and ever-growing array of voice processing sub-technologies.
A proposed solution to solve this long-felt need has been to connect a VM and IVR system together through a signalling link that coordinates the two systems. This link allows the systems to exchange calls with proper information relating to each call and which generates consolidated report. However, the customer must still purchase discrete systems, and this solution is akin to suggesting that the customer purchase a personal computer with a word processing package of choice, another personal computer with, for example, a spreadsheet program, and yet another personal computer with a graphics program. Clearly, this is a cost prohibitive and ineffective way of performing a plurality of voice processing tasks and is not acceptable in light of the realities of today's business markets.
Another proposed solution to the integration problem has been to package two or more discrete systems in a large cabinet. Usually, systems having a large cabinet have nothing in common except the cabinet itself. The systems may have their own separate consoles and keyboards, or they may have an A/B switch to share a single console yet still retain their individual keyboards. In all such "cabinet" systems, there is coexistence of applications but not integration of applications. Furthermore, systems which provide coexistence of applications usually provide hard-coded software in C-language, while the rest of the application development environment consists of C-language functions and programmer documentation that can only be understood by an expert programmer, but not by a customer who may require versatility and ease of use. Thus, the aforementioned integration attempts do solve the long-felt need in the art for a truly integrated voice processing system.
Yet another attempted solution to the integration challenge has been to use a fixed VM system or a fixed IVR system and modify the resultant composite system to provide VM and IVR functions for execution in tandem on a common computer. The results of such machinations have been mixed, and the customer generally ends up with an inflexible VM or IVR system wherein the limitations and problems of one half of the system dictate the abilities and utility of the other half.
Examples of attempts at integration can be found in U.S. Pat. No. 4,792,968 to Katz. The Katz patent discloses a system of analysis selection and data processing for operation and cooperation with a public communication facility, for example a telephone system. See Katz, col. 1, lines 57-60. The systems disclosed in Katz provide methods of selecting digital data to develop records for further processing and allowing a caller to interface directly with an operator. See Katz, col. 1, lines 62-68. Another example of an attempt at integration may be found in U.S. Pat. No. 4,748,656 to Gibbs et al. The Gibbs et al. patent discloses an interface arrangement implemented on a personal computer to provide business communication services. See Gibbs et al., col. 2, lines 8-12. The personal computer interprets appropriate control signals which are then forwarded under control resident software to activate a telephone station set and provide communication services. See Gibbs et al., col. 2, lines 18-28.
Another integration attempt is disclosed in U.S. Pat. No. 4,893,335 to Fuller et al., which teaches a telephone control system that produces control signals which are programmable to provide a variety of control functions to a remote user, including for example, conferencing and transferring functions. See Fuller et al., col. 2, lines 7-44. However, in all of the above-referenced attempts at integration, only limited applications are achievable and significant problems of interfacing the different voice transactions are encountered. These aforementioned attempts at integration simply do not provide high level and effective voice transactions.
The inventor of the subject matter herein claimed and disclosed has also recognized another problem facing the task of integrating VM with IVR and other voice processing systems. Caller interfaces present a significant problem in integration since VM systems generally have fixed, hard-coded interfaces. In an integrated environment, this restricts the versatility of the entire integrated system, since it confines the system to the limitations of the original design of the VM interface. For example, if an IVR system provides voice responses to an airline for crew scheduling, it is unlikely that an IVR system could understand an employee number, translate it to an extension, look up the caller's supervisor and automatically transfer or drop the message in the supervisor's mailbox without querying the caller. The VM interface is usually inadequate to perform such complex tasking in an economical fashion. Thus, a fixed VM system quickly dominates the more flexible IVR system when the two systems attempt to operate together and the necessary VM caller interface is introduced in a pseudo-integrated environment. Such pseudo-integration schemes to put different voice processing applications together have heretofore simply not been able to accomplish the multifarious complex voice transactions required. Prior integrated systems do not solve the long-felt need in the art for a truly universal integrated voice processing telecommunications system.
During the evolution of the voice processing industry, VM systems have not been customized to perform according to a particular customer's unique specifications. Thus, VM-type systems were developed in mostly hard-coded traditional programming languages such as the C-language or Pascal language. In contrast, IVR systems were generally more sophisticated and employed primitive customization for particular applications. The IVR systems were thus generally designed in higher level programming language known as "scripted languages." Scripted languages merely replace the C-language or Pascal knowledge requirements of the system developer with that of the Basic language.
The common problem which emerges with the use of scripted languages is a disorientation of the system developer when designing the flow of the particular application. Furthermore, most scripted languages require several dozens of pages of basic code to accomplish even a simple programming task. Even though scripted programs can be interpreted by a programmer having less expertise than that which would be required if the software programs were written in the more traditional C-language or Pascal language, it will be recognized by those with skill in the art that after even a few pages of the length scripted code have been reviewed, the entire flow of the application becomes disjoint and escapes the normal comprehension of even the most expert programmers in scripted languages.
In order to devise ways of alleviating the problems extant in scripted software voice processing systems, the concept of a state, event and action to define applications having programming methodologies in, for example, C-language or Pascal have been developed. Example of such systems are disclosed in U.S. Pat. No. 4,747,127 to Hansen et al The Hansen et al. patent describes methods of implementing states, events, and actions to control a real-time telecommunications switching system. The method of performing voice processing transactions in the Hansen et al. patent are accomplished using a scripted base language similar to the "SHELL" programming language used by the AT&T UNIX System V operating system. See Hansen et al., col. 7, lines 15-35.
The methods and systems described in the Hansen et al. patent are strictly limited to telecommunications switches on a PBX. While the implementation of states, events and actions to perform higher level voice transactions is desirable, the systems and methods disclosed in the Hansen et al. patent do not fulfill the long-felt need in the art for integrated voice processing systems adaptable to provide multiple functions in a single, general-purpose computer environment and for varying customized applications. Furthermore, the use of non-traditional script base high-order programming language severely limits the adaptability of systems taught in the Hansen et al. patent, and thus the systems and methods disclosed in the Hansen et al. patent cannot be manipulated to provide integrated voice processing transactions.
Furthermore, voice mail systems have proliferated in the last few years and almost every type of company, large and small, is either utilizing voice mail systems in-house or leasing voice mail boxes from service providers. Companies are making significant investments in voice mail in terms of equipment, training, and service contracts. The productivity benefit of voice mail alone has proven to be enough of a reason for adding voice mail to the office environment. Now voice mail has become an expected productivity tool in almost all segments of the business community. To provide consistent corporate communications, companies are installing voice mail systems in each of their offices, and often networking them together. These corporate-wide installations require significant investment both in terms of equipment and in user training and maintenance. Service providers of voice mail, like the regional telephone companies and voice mail service bureaus, are installing voice mail systems in their networks at considerable expense, including voice mail machines in their central offices. In order to provide ubiquitous services, this requires the installation of thousands of machines. These installations require considerable investment in equipment, training, and maintenance. And in the case of service providers it also includes advertising, promotion, and sales expenses.
Voice mail systems from different vendors have their own proprietary user interfaces and feature sets. While most of them provide a core set of voice mail features, each one differs in the way it interacts with the callers. Advanced features differ from vendor to vendor even more so than the core features. There are no adhered-to standards in the voice mail industry for caller interfaces. Each vendor provides its own version of voice mail. While there are some efforts towards industry standard voice mail, most large vendors choose to accept in principle but ignore in practice the proposed standards, as acceptance of standards would open the installed base of these vendors to competition. The VMUIF (Voice Messaging User Interface) and the AMIS (Audio Messaging Interchange Standard) propositions for the most part remain propositions that have yet to be adopted by large, established vendors of voice mail systems.
Companies implementing voice mail on a corporate-wide bases, or service-providing companies desiring to offer voice mail services, are faced with a difficult decision. In order to obtain economies of scale in training and servicing they must install a one vendor solution. Yet, in order to lower their cost and promote competition they must be able to take advantage of equipment from multiple vendors. Bell companies find themselves in the position of having spent millions of dollars on voice mail equipment from a single vendor, and being locked into that single vendor now that all the subscribers are used to that vendor's voice mail interface. They are now forced to go back to the same vendor for new equipment, upgrades and enhancements. This makes for a continuous source of revenue on inflated prices for the large, established vendor and crushes competition.
All of the above-referenced patents disclose voice mail systems that comprise single fixed caller interfaces (call flows). If a customer was to deploy a voice mail device based upon one or more of those patents from any one of the voice mail vendors today, that customer would either have to purchase additional systems from the same vendor for years to come or risk the chaos and confusion which would result from mixing systems from multiple vendors.
Thus, a need has arisen for a system that is flexible enough to allow configuration of caller interfaces to meet specific application requirements, and to emulate operation of other systems.